Gestión de paquetes es un concepto que se utiliza frecuentemente en este libro. Un administrador de paquetes permite el seguimiento de la instalación de los archivos por lo que es fácil quitar y actualizar los paquetes. Además de los archivos ejecutables y las librerias de utilidades, un gestor de paquetes se encargará de la instalación de los archivos de configuración. Antes de que te hagas la pregunta. . . .NO!!, esta sección no trata de recomendar un sistema gestor de paquetes u otro. Lo que ofrece es un resumen de las técnicas más populares y cómo funcionan. El gestor de paquetes perfecto para ti puede encontrarse entre estas técnicas o puede ser una combinación de dos o más de estas técnicas. Esta sección menciona brevemente los problemas que puedan surgir al actualizar paquetes.
Algunas razones por las que no se recomienda o menciona ningún administrador de paquetes en particular en LFS o BLFS son estas:
Hacer frente a la gestión de paquetes no forma parte de los objetivos de este libro, el cual, enseñanza cómo se construye un sistema Linux.
Existen múltiples soluciones para la gestión de paquetes, cada uno con sus puntos fuertes y sus inconvenientes. Incluir uno que satisfaga a todos los públicos es difícil.
Algunos consejos acerca de los gestores de paquetes puede encontrarlos en Proyecto Hints visítelo y tome sus propias decisiones.
Un administrador de paquetes facilita la actualización a nuevas versiones cuando sean liberadas. Generalmente las instrucciones de LFS y BLFS se pueden utilizar para actualizar a las nuevas versiones. He aquí algunos puntos que se deben tener en cuenta cuando actualices paquetes, especialmente en un sistema en funcionamiento.
Si uno de los paquetes de las herramientas (Glibc, GCC o Binutils) necesita ser actualizado a una nueva versión menor (es decir, el segundo grado de serialización), es más seguro reconstruir LFS completo. Aunque usted puede ser capaz de reconstruir todos los paquetes en orden de dependencia, algo que no lo recomendamos. Por ejemplo, si glibc-2.2.x necesita ser actualizado a glibc-2.3.x, es más seguro la reconstrucción completa. Para micro actualizaciones de versión, una simple reinstalación funciona normalmente, pero no está garantizada. Por ejemplo, actualizar de glibc-2.3.4 a glibc-2.3.5 no suele causar ningún problema.
Si se actualiza un paquete que contiene una biblioteca compartida, y si el nombre de la biblioteca cambia, entonces todos los paquetes enlazados dinámicamente a la biblioteca necesitan ser recompilados para enlazar con la biblioteca nueva. (Tenga en cuenta que no existe una correlación entre la versión del paquete y el nombre de la biblioteca.) Por ejemplo, pensemos en el paquete llamado foo-1.2.3 que instala una librería compartida con el nombre libfoo.so.1 . Digamos que actualizas el paquete a una versión foo-1.2.4 más nueva que instala una librería compartida con el nombre libfoo.so.2 . En este caso, todos los paquetes que están enlazados dinámicamente a libfoo.so.1 tienen que ser recompilados para enlazar con libfoo.so.2 . Tenga en cuenta que usted no debe eliminar las librerías anteriores hasta recompilar los paquetes dependientes.
Las siguientes son algunas de las técnicas comunes de gestión de paquetes. Antes de tomar una decisión sobre un gestor de paquetes, conviene hacer una investigación sobre las diversas técnicas, en particular sobre los inconvenientes de cada cada una.
Sí, esta es una técnica de gestión de paquetes. Algunas personas no encuentran la necesidad de un gestor de paquetes porque conocen íntimamente los paquetes y saben qué ficheros instala cada paquete. Algunos usuarios tampoco necesitan la gestión de paquetes, porque piensan reconstruir todo el sistema cuando se cambia un paquete.
Este es un sistema de gestión de paquetes muy simple que no necesita elementos adicionales para gestionar el software. Cada paquete se instala en un directorio independiente. Por ejemplo, se instala el paquete foo-1.1 en /usr/pkg/foo-1.1 y un se crea un enlace simbólico de /usr/pkg/foo a /usr/pkg/foo-1.1 . Cuando se instale una nueva versión foo-1.2, que debería ubicarse en /usr/pkg/foo-1.2 el enlace simbólico anterior se sustituye por uno de igual nombre pero a la nueva versión.
Las variables de entorno, como PATH , LD_LIBRARY_PATH , MANPATH , INFOPATH y CPPFLAGS deben ser modificadas para incluir /usr/pkg/foo . Para más de un par de paquetes este esquema se hace inmanejable.
Esta es una variación de la técnica anterior. Cada paquete se instala de forma similar al esquema anterior pero en lugar de hacer un enlace en el mismo directorio de la instalación, cada fichero se enlaza en la jerarquía de directorios que cuelgan de /usr. Esto elimina la necesidad de modificar las variables de entorno. Aunque los enlaces simbólicos pueden ser creados por el usuario para automatizar la creación, muchos gestores de paquetes se han escrito utilizando este enfoque. Algunos de los más populares son Stow, Epkg, Graft, y Depot.
La instalación debe ser falsa para que el paquete piense que se instala en /usr aunque en realidad se instala en el /usr/pkg. Instalar de esta manera no es generalmente una tarea trivial. Por ejemplo, supongamos que vamos a instalar un paquete llamado libfoo-1.1. Las siguientes instrucciones no instalarán el paquete correctamente:
./configure --prefix=/usr/pkg/libfoo/1.1 make make install
La instalación va a funcionar, pero los paquetes dependientes no puede enlazar a libfoo como cabría esperar. Si posteriormente compila un paquete que enlaza con libfoo, usted observará que se vinculado a /usr/pkg/libfoo/1.1/lib/libfoo.so.1 en lugar de /usr/lib/libfoo.so.1 como es de esperar . El enfoque correcto es utilizar la estrategia DESTDIR para falsear la instalación del paquete. Este técnica funciona de la siguiente manera:
./configure --prefix=/usr make make DESTDIR=/usr/pkg/libfoo/1.1 install
La mayoría de los paquetes admiten esta forma de instalación pero hay algunos que no lo hacen. Para los paquetes que no cumplen, puede ser necesario instalar manualmente el paquete, o como alternativa se puede instalar en /opt .
En esta técnica, un archivo se marca con la fecha antes de la instalación del paquete. Después de la instalación, haciendo uso del comando find con las opciones apropiadas se puede generar un registro de todos los archivos instalados después de la creación del archivo "timestampado". Un gestor de paquetes creado con este enfoque es install-log.
Aunque este esquema tiene la ventaja de ser muy simple, tiene dos inconvenientes. Si, durante la instalación, los archivos se instalan con una marca de fecha que no sea la actual, estos ficheros no serán registrados por el gestor de paquetes. Además, este sistema sólo puede ser utilizado cuando un paquete se instala en un momento determinado y de forma continuada. Los registros no son confiables si dos paquetes se están instalando en dos consolas diferentes.
Con este método, se registran los comandos que los scripts de instalación ejecutan. Hay dos técnicas que se pueden utilizar:
La variable de entorno LD_PRELOAD puede configurarse para que apunte a una libreria que se cargue antes de la instalación. Durante la instalación esta librería supervisa los paquetes que se están instalando uniéndose a varios ejecutables como cp, install, mv registrando las llamadas al sistema que modifican el sistema de ficheros. Para que este método funcione, todos los ejecutables deben estar vinculados de forma dinámica sin el suid o bit SGID. Precargar la librería puede causar algunos efectos secundarios no deseados durante la instalación. Por lo tanto, se aconseja que se realicen algunas pruebas para asegurarse de que el gestor de paquetes no rompe nada y registra todos los ficheros necesarios.
La segunda técnica es utilizar strace, que registra todas las llamadas al sistema hechas durante la ejecución de los scripts de instalación.
En este esquema, la instalación del paquete es falseada en un árbol separado como se describe en la gestión de paquetes a través de enlaces simbólicos. Después de la instalación, un archivo de paquetes se crea utilizando los archivos instalados. Este archivo se utiliza para instalar el paquete en la máquina local, o incluso se puede utilizar para instalar el paquete en otras máquinas.
Este método es utilizado por la mayoría de los gestores de paquetes que se encuentran en las distribuciones comerciales. Ejemplos de administradores de paquetes que siguen este método son RPM (que, por cierto, es el que establece la norma Linux estándar Base Especificación ), pkg-utils, apt de Debian, y el sistema Portage de Gentoo. Información acerca de cómo adaptar este estilo de gestión de paquetes para sistemas LFS se encuentra en http://www.linuxfromscratch.org/hints/downloads/files/fakeroot.txt .
Creación de archivos de paquetes que incluyen la información de dependencia es complejo y está más allá del alcance de la LFS.
Slackware utiliza un sistema de creación de archivos de paquetes basado en el comando tar. Este sistema, deliberadamente, no maneja las dependencias de paquetes como hacen los gestores de paquetes más complejos. Para más detalles sobre la gestión de paquetes de Slackware, consulte http://www.slackbook.org/html/package-management.html .
Este esquema, propio de LFS, fué desarrollado por Matthias Benkmann, y está disponible en Hints Project . En este esquema, cada paquete se instala como un usuario diferente dentro de los lugares habituales. Los archivos pertenecientes a un paquete se identifican fácilmente comprobando el ID de usuario. Las características y particularidades de este método son demasiado complejos para ser descritas en esta sección. Para los detalles, visitehttp://www.linuxfromscratch.org/hints/downloads/files/more_control_and_pkg_man.txt .
Una de las ventajas de un sistema LFS es que no hay archivos que dependen de la posición de los archivos en un sistema de disco. La clonación de un LFS para otro ordenador con una arquitectura similar es tan sencillo como utilizar tar en la partición LFS que contiene el directorio raíz (unos 250 MB sin comprimir para una construcción de LFS base), copiar el archivo resultante,a través de la red o un soporte removible al nuevo sistema y desempaquetarlo. A partir de ese punto, algunos archivos de configuración tendrán que ser modificados. Los archivos de configuración que pueden necesitar una actualización serían: /etc/hosts, /etc/fstab, /etc/passwd, /etc/group, /etc/shadow, /etc/ld.so.conf, /etc/sysconfig/rc.site, /etc/sysconfig/network, and /etc/sysconfig/ifconfig.eth0.
Un kernel personalizado puede necesitar ser reconstruido para el nuevo sistema en función de las diferencias en el hardware del sistema y la configuración original del kernel.
Por último, el nuevo sistema tiene que ser iniciable tal y como se describe enSección 8.4, "Usando GRUB para configurar el proceso de arranque" .